Cloudflare SWG — Demo Cheat Sheet
~20–25 min · Mac with WARP · Browser-driven · Five live blocks
Pre-demo setup checklist
- WARP client connected on your Mac (menu bar icon green, team = tarheel23)
- Cloudflare root cert in Keychain → Always Trust
- Logged into Zero Trust dashboard (
one.dash.cloudflare.com)
- Browser tabs queued:
- Tab 1 — fresh Chrome window for live browsing demos
- Tab 2 — Gateway → Firewall policies (show the rules)
- Tab 3 — Logs → Gateway → HTTP / DNS (for the live log pivot)
- Terminal open for the curl-based verifications (cf-ray check etc.)
- Pre-flight:
curl -sI https://example.com | grep cf-ray should return a cf-ray header
- Optional fast path:
traffic-gen script present on the WARP box driving the demo (used in Step 7b to fire every policy at once and seed the logs)
Required Gateway policies (deploy before demo)
- DNS — Block Security Threats (Malware, Phishing, C2, Cryptomining)
- HTTP — Block Gambling category
- HTTP — Isolate Newly Seen Domains
- HTTP — Block PII uploads (DLP profile attached, with at least one detection entry enabled — see note below)
DLP gotcha: the DLP profile must have at least one detection entry enabled (e.g. US SSN). A profile with zero enabled detectors matches nothing and the upload sails through — the policy page shows a yellow "enable at least one detection entry" warning. Also check the policy's identity condition isn't excluding the account your WARP box is enrolled as.
1. Open — Why SWG (~2 min)
"Every company has the same problem. Users browse the internet from home, from coffee shops, from airports. They click on things they shouldn't. They paste sensitive data into the wrong forms. They get phished. And the traditional firewall in your data center doesn't see any of it — because the user never went through the data center."
"Cloudflare's Secure Web Gateway fixes that by putting the inspection layer at the edge — 330+ data centers worldwide. Wherever your user is, the closest Cloudflare data center is the inspection point. Same policies, same enforcement, whether they're at HQ, at home, or on a hotel WiFi."
"I'm going to demo this from my own Mac — WARP-enrolled, cert installed. We'll see DNS filtering, URL category blocking, file upload blocking via TLS decryption, Browser Isolation, and DLP — all live. Then we'll pivot to the dashboard and see every decision recorded."
The five capabilities you'll see
- DNS filtering — block known-bad domains before TCP opens
- URL category enforcement — gambling, social media, streaming with one click
- TLS decryption + HTTP inspection — see inside HTTPS, block by method/content-type
- Browser Isolation — risky sites in a remote sandbox, streamed safely
- Data Loss Prevention — PII / PCI can't leave through forms or uploads
2. Verify Gateway is Inspecting My Traffic (~1 min)
▶ Terminal
SETUP — Confirm WARP + Gateway are active
curl -sI https://example.com | grep -iE "cf-ray|server"
"cf-ray header is present. From this moment, every packet leaving this Mac is policy-checked by Gateway."
3. DNS Filtering — The First Line of Defense (~3 min)
▶ Dashboard Tab 2: Gateway → Firewall policies → DNS
"The cheapest, fastest security control is stopping a connection before it even opens. If a user tries to visit a phishing site, Cloudflare returns 'this is blocked' — and the browser can't even start a connection to the attacker."
Show the policy:
- Block Security Threats → DNS · Security Categories = Malware, Phishing, C2, Cryptomining → Block
TEST 1 — Visit a known malicious test domain → BLOCKED at DNS
▶ Browser Tab 1 → navigate to http://malware.testcategory.com
"Cloudflare block page appears. 'This site is blocked. It matches the Malware category.' The DNS query never resolved to the real IP — Cloudflare returned its block IP instead. Page never loaded. TCP connection never opened."
▶ Pivot to Dashboard Tab 3: Logs → Gateway → DNS. Filter by domain. Show event: user, device, action, category, timestamp.
"Imagine a real user clicks a phishing link in an email. DNS query goes out, Cloudflare returns the block, page never loads. And we already know about it — before any incident response, before any post-breach forensics."
4. URL Category Enforcement (~3 min)
▶ Dashboard Tab 2: Gateway → Firewall policies → HTTP
"DNS handles security. URL categories handle policy. 80+ pre-built categories — gambling, adult content, streaming, social media, file sharing — block with one click. Categorization is automatic, Cloudflare keeps it updated as new sites appear."
Show the policy:
- Block Gambling → HTTP · Content Categories = Gambling → Block
TEST 2 — Visit a gambling site → BLOCKED at HTTP
▶ Browser Tab 1 → navigate to https://www.bovada.lv (or any well-known gambling URL)
"Cloudflare block page. 'This site has been blocked by your security team.' The block happens at the HTTP layer — Cloudflare inspected the URL, looked up the category, matched the policy."
"Want to allow finance team for market data sites that share infrastructure? Add an exception by IdP group. Want to log only? Change the action. Want a custom block page with your helpdesk contact? Edit the template."
5. TLS Decryption + HTTP-Level Policy (~4 min)
▶ Dashboard: Settings → Network → TLS decryption — confirm ON
"95% of internet traffic is HTTPS. Without TLS decryption, your SWG sees the destination but not the request. With it on, you see method, path, headers, body, file uploads, file downloads — everything."
"Cloudflare's root cert lives in the device trust store. Decrypted at the edge, inspected, re-encrypted, forwarded. The user sees no cert warnings."
TEST 3 — Block file uploads to personal file sharing → BLOCKED on POST
▶ Show this policy in the dashboard:
- Block uploads to personal file shares → HTTP · Application = WeTransfer · Method = POST · Action = Block
▶ Browser Tab 1 → navigate to https://wetransfer.com
▶ Try to drag-and-drop or select a file to upload
"Upload blocked. Notice — we didn't block the whole site. I can still browse wetransfer.com, read the marketing pages. We only blocked the POST that carries the file. Reading marketing content: fine. Uploading data: blocked."
"This is what TLS decryption unlocks. Before decryption, this whole exchange looks like encrypted bytes to your firewall. After decryption, Cloudflare sees 'this is a multi-megabyte file being uploaded to a personal file share' and acts on it."
6. Browser Isolation — Risky Sites Without the Risk (~3 min)
▶ Dashboard Tab 2: Gateway → Firewall policies → HTTP
"Sometimes you don't want to block — you want users to access something but without any malware risk. That's Browser Isolation. The site loads in a remote Chrome instance running in a Cloudflare data center. A safe pixel stream is sent back to the user. Malware on the page executes in Cloudflare's sandbox, never on the user's device."
Show the policy:
- Isolate Newly Seen / Uncategorized → HTTP · Categories = Newly Seen, Uncategorized → Isolate
TEST 4 — Visit an isolated site → RENDERED IN REMOTE BROWSER
▶ Browser Tab 1 → visit a newly-registered or obscure domain
"The site loads. Looks normal. But check DevTools → Network — everything is going through Cloudflare's isolation service. What's actually rendering is a remote browser in a Cloudflare data center. The user gets pixels. No JavaScript ran locally. No malware touched the device."
"You can also restrict actions inside the isolated session — disable copy/paste, disable downloads, disable printing, disable form submission. Real-world use case: legal team reads documents on external sites in isolation, but can't accidentally upload internal contracts back to the same site."
7. Data Loss Prevention (~4 min)
▶ Dashboard Tab 2: Gateway → DLP → Profiles
Show this DLP profile + policy:
- Profile: US PII → US SSN, Credit Card, US Driver's License
- Policy: Block PII uploads → HTTP · DLP profile matches → Block
"Most security incidents aren't malware — they're data walking out the front door. Employee pastes customer PII into ChatGPT. Engineer commits an API key to personal GitHub. DLP catches it."
TEST 5 — Submit an SSN in a form → BLOCKED by DLP
▶ Browser Tab 1 → navigate to https://httpbingo.org/forms/post
▶ In the Customer name field, type a fake-but-format-valid SSN: 123-45-6789
▶ Click Submit
"Blocked. Cloudflare's DLP engine inspected the POST body, matched the SSN pattern, refused to forward to the destination."
"Scope this — block uploads to ChatGPT and Slack, log to internal HR portal. Write custom patterns — your customer ID format, your internal API key prefix, the format of your source code. One engine, every type of sensitive data, every place it might leave."
"And — Cloudflare logs the category that matched, not the matched value. We don't store PII in logs."
▶ Pivot to Dashboard Tab 3: Logs → Gateway → HTTP. Filter by DLP. Show event with profile name attribution.
7b. Optional — Fire Every Policy at Once (~1 min)
▶ Terminal (the WARP box driving the demo) · run: traffic-gen
"Instead of clicking through sites one at a time, I can push a whole batch through Gateway in one shot and watch every policy react at once."
traffic-gen — color-coded proof across a list of sites
traffic-gen
"This script hits a list of sites through Gateway and color-codes what happened to each one.
GREEN — ALLOWED. Clean traffic, no policy matched.
RED — BLOCKED. Malware, gambling, disallowed categories.
PURPLE — ISOLATED. Newly seen and uncategorized sites open in the remote browser.
Same box, same network, different outcomes, every decision made at the edge in milliseconds. And it seeds the logs, so when we pivot to the dashboard next it's already full of fresh events to point at."
8. One Place for Every Decision (~2 min)
▶ Dashboard: Insights → Analytics → Gateway · also Insights → Logs
"Everything we just demoed shows up here. Every DNS query. Every HTTP request. Every block. Every isolation event. Every DLP match. One feed, every user, every device."
What to point at:
- Top blocked domains — what users try to reach that they shouldn't
- Top users by traffic — anomalies surface immediately
- Top categories — where is the traffic going?
- DLP detections over time — is data egress increasing?
- Filter by user / device / IP / category / domain — any incident question in 3 clicks
"When somebody says 'we think Mayah has been exfiltrating data,' you're not stitching firewall logs together with proxy logs and email logs at 2am. Filter by user = Mayah. Done."
THE ARCHITECTURAL POINT
DNS → blocks malicious before TCP opens
Category → policy enforcement on what users browse
TLS decryption → inspection inside HTTPS
Isolation → risky sites without the malware risk
DLP → sensitive data can't walk out the door
"All five run at the same edge — 330+ data centers. Wherever your user is, the inspection is already there. No backhaul, no appliance, no third VPN. One client, one policy plane, one log stream."
Quick Troubleshooting Reference
Logs are empty in the dashboard
- WARP icon should show Connected with team name (tarheel23)
- WARP mode should be Gateway with WARP (full L7) — not just WARP or 1.1.1.1 with WARP
- Run:
curl -sI https://example.com | grep cf-ray — cf-ray header confirms Gateway is in the path
HTTPS sites show cert errors
Cloudflare root cert isn't trusted. Re-download from Settings → Resources → Certificates. In Keychain Access → System → set to Always Trust.
Cert-pinned apps break with TLS decryption
Zoom, Teams, banking apps, some agent binaries pin certificates and break under TLS inspection. Solution: Do Not Inspect HTTP policy matching those domains/applications. Standard practice on every SWG.
DLP not catching what I expect
- Profile has no detection entries enabled — most common cause. Open the DLP profile and toggle on at least one detector (e.g. US SSN). A profile with zero enabled entries matches nothing; the policy page flags this with a yellow warning.
- If the SSN detector has a "require additional context" option, turn it off for the demo — a bare SSN in a form field has no surrounding keywords to satisfy it.
- Identity condition on the policy may be excluding you (e.g.
User Email is not you@example.com blocks everyone except that address) — confirm which identity the WARP box is enrolled as.
- DLP profile must be attached to an HTTP policy (creating the profile alone does nothing)
- TLS decryption must be ON
- Some content types (images, binaries) aren't scanned by default — check profile config
- Placeholder value
123-45-6789 can be skipped by some detectors — a realistic format-valid SSN like 512-74-8391 is safer
Browser Isolation not isolating
- Policy action must be Isolate, not Allow or Block
- Root cert must be installed (Isolation rewrites HTTPS responses)
- Some very old browsers don't support the Isolation protocol — confirm Chrome / Edge / Safari current
Q&A — back-pocket answers
How does this compare to Zscaler / Netskope / Palo Alto Prisma Access?
- Same edge as everything else Cloudflare does — no separate inline component, no separate identity store
- Network advantage — Cloudflare sees ~20% of all internet traffic, so threat intel and categorization is unmatched
- One client — WARP does SWG + ZTNA + DNS filtering. Competitors often require 2-3 agents
- One policy language — combine SWG rules with WAF, bots, identity, access
- No POP capacity question — Cloudflare's network is built for hyperscale workloads (Workers, R2, AI)
Do we have to install certs on every device?
Yes, for TLS decryption — same as every other inline SWG. MDM push handles it: Intune, Jamf, Kandji, Workspace ONE all supported. Without the cert, you can still do DNS filtering and basic categorization, just not body inspection or DLP.
What about cert-pinned apps (Zoom, Teams, banking)?
Add a Do Not Inspect HTTP policy matching those domains. Cloudflare passes the encrypted bytes through without breaking the pinning. Every SWG product handles this the same way.
Will this slow down browsing?
No — usually faster. Cloudflare's edge is closer to your users than your data center is. Inspection adds single-digit milliseconds. Most customers see browsing get faster after deployment.
What about users not on WARP?
You have options: PAC file (browser-based forwarding), DNS-only enforcement, IPsec/GRE tunnel from office networks, proxy chaining. WARP gives the deepest enforcement and best UX, but it's not the only on-ramp.
How do we onboard 5,000 users?
Push WARP via MDM with a pre-configured profile. Devices auto-enroll using your IdP. Cert auto-installs. Users see the WARP icon appear and that's it — zero clicks for them. Bulk rollouts are typically 2-4 weeks, mostly testing not technical work.
What if Cloudflare blocks something legitimate?
Set policies to Log first to observe before enforcing. Users see a Cloudflare block page with a request-access button — they can self-service request an exception that goes to your security team's queue.
What data does Cloudflare store?
Logs contain metadata: source, destination, action, category, timestamp, identity. Cloudflare does NOT store request/response bodies. DLP logs the category that matched, not the value. SOC 2, ISO 27001, FedRAMP Moderate.
Air-gapped or no-internet environments?
SWG is a cloud service — by definition, it needs internet. For air-gapped, use Cloudflare's on-prem options (Magic Firewall, Magic Transit). Different product set.
How quickly can we deploy a pilot?
If you already have an IdP and MDM: 1-2 days to a small pilot group. Configure WARP enrollment policy → push WARP + cert via MDM → set a few starter policies → start watching logs. Full org rollout is weeks not months.